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Abstract 

The full power of mobile augmented and virtual reality systems is realized when 
these systems are connected to one another, to immersive virtual environments, 
and to remote information servers. Connections are usually made through wireless 
networks. However, wireless networks cannot guarantee connectivity and their 
bandwidth can be highly constrained. This paper presents a robust event-based data 
distribution mechanism for mobile augmented reality and virtual environments. It is 
based on replicated databases, pluggable networking protocols, and communication 
channels. The mechanism is demonstrated in the Battlefield Augmented Reality Sys¬ 
tem (BARS) situation awareness system, composed of several mobile augmented 
reality systems, immersive and desktop-based virtual reality systems, a 2D map- 
based multimodal system, handheld PCs, and other sources of information such as 
external data servers. 
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I Introduction 

As computers have become smaller and more powerful, portable, even 
wearable, high-performance computer systems for augmented and virtual real¬ 
ity have become feasible. State-of-the-art laptops and small-form-factor PCs 
boast processor, memory, disk, and graphics hardware that rival supercomput¬ 
ers from only five years ago. These PCs can be built into wearable (but still 
bulky) computer systems for individuals that provide information through a 
head-worn display. The full power of these systems is realized when these sys¬ 
tems are networked with one another and with remote information servers. 

For example, a user walking down a street might be able to see the locations of 
other users, up-to-date information about prices in shop windows, and even 
email (Feiner, 2002). The focus of our research on the Battlefield Augmented 
Reality System (BARS) (Julier, Baillot, Lanzagorta, Brown, & Rosenblum, 
2000; Livingston et ah, 2002) is on the problem of developing information 
systems able to provide users with situation awareness, that is, data about the 
environment and its contents. 

The problem of distributing data to users of wearable systems is somewhat 
unusual. Most research into distributed virtual reality focuses on the support of 
common, consistent virtual worlds that replace the real world, typically main¬ 
tained by a small number of users. However, the objective of BARS is to sup¬ 
port a consistent information space that augments the real world, one that 
does not need to provide a simulated replacement for the real world. There- 
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fore, data objects tend to be less complicated, contain¬ 
ing mainly semantic information instead of detailed 
geometry and textures, and updates may occur less fre- 
quendy than in virtual environments. Furthermore, 
BARS requires a unified architecture that allows trans¬ 
port of general state information that can be used for 
many purposes, such as the obvious task of distributing 
augmenting information, as well as more general uses 
such as “remote control” of applications, in which a 
remote device such as a PDA controls another com¬ 
puter. This system must also handle the poor network 
connectivity that can sometimes be encountered in mili¬ 
tary operations. Given these parameters, we have devel¬ 
oped a robust, flexible, and general event-based net¬ 
working infrastructure for data distribution. The 
mechanism builds upon three techniques: distributed 
databases, pluggable transport protocols, and a high- 
level management technique known as channels. 

The structure of this paper is as follows: The problem 
statement and a survey of existing literature are given in 
Section 2. Section 3 describes the event distribution 
system. Representative performance measurements are 
presented in Section 4. Conclusions and future work are 
discussed in Section 5. 


1 Problem Statement 

The Battlefield Augmented Reality System 
(BARS) is a collaborative mobile augmented reality sys¬ 
tem designed to improve the situation awareness of, and 
the coordination among, members of a team of mobile 
users. Improving situation awareness means that each 
user obtains a better understanding of the environment 
through enhanced sensory perception. The types of data 
include the names of buildings, routes, objectives, and 
the locations of other users. While short-range radio 
communications can accomplish much of this data pre¬ 
sentation, the passive and natural display paradigm of 
augmented reality makes the internalization of the in¬ 
formation by an individual faster and easier. 

The hardware of a prototype wearable system is 
shown in Figure 1. It consists of a wearable computer, a 
display, and a tracking system. The computer is respon- 



Figure I. The BARS Wearable. 


sible for generating 3D graphics and spatialized audio in 
real time. The generated graphics are shown on an opti¬ 
cal see-through head-mounted display. The tracking 
system determines the position and orientation of the 
user’s head, using a Global Positioning System (GPS) 
receiver for position and a solid-state inertial navigation 
system for orientation. A camera can be used for track¬ 
ing and sending video reports to a base station. The 
user operates the system using a cordless mouse and a 
wrist keyboard. Wireless 802.Ilb networking is used for 
data distribution and GPS corrections. Future mobile 
Augmented Reality (AR) systems will communicate us¬ 
ing a hardened military networking system (North, 
Bryan & Baker, 1999), but it is probable that any such 
system will still be vulnerable to connectivity and band¬ 
width complications in urban areas, and the distribution 
system design reflects that consideration. 

The BARS mobile user sees computer graphics super¬ 
imposed on or next to the real objects they are intended 
to augment, in addition to status information such as 
compass direction and messages from other users. Fig¬ 
ure 2 shows a view using the system, in which another 
BARS user is augmented and is following a virtual path. 
This application has a number of characteristics that im¬ 
pact the distribution of information and events between 
users: 
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Figure 2. A sample augmentation. 


• The objective is to provide relevant information, 
not a consistent virtual world. The BARS environ¬ 
ment is populated by a set of objects that are self- 
contained entities and other types of discrete data. 
Each object can be relatively simple, representing a 
building type and location, an avatar to symbolize 
another user, the location of a hazard, and so on. It 
is not necessary to transmit complicated geometric 
objects or behaviors—only semantic information. 
The latency in the update of an object or an entity 
is a secondary consideration. 

• Data distribution between users can be hetero¬ 
geneous. Different users might perform different 
tasks and thus have different information require¬ 
ments. 

• The distribution system should facilitate collabora¬ 
tion between users. In addition to environmental 
data, the distribution system must support the 
propagation of metadata such as task assignments, 
objectives, and personalized messages. 

• Users should have the ability to create reports and 
update entities in the database. For example, a user 
might observe that an environmental feature (such 
as a vehicle) is not where the database indicates it 
should be. The user should have the ability to move 
the object to its correct location. 

• Network connectivity is unreliable. As a user 
traverses a terrain, reception strength and band¬ 
width may vary. 


Given the potential importance of distributed systems 
for virtual and augmented reality, a great deal of re¬ 
search has been carried out by various research groups. 

The Naval Postgraduate School (NPS) has been 
working on large-scale distributed virtual environments 
for over a decade, their first version of NPSNET being 
shown in 1991. The data distribution in the current 
version, NPSNET V (Capps, McGregor, Brutzman, & 
Zyda, 2000), uses replicated data and the model-view- 
controller paradigm to maintain it. Users of the system 
see a view of the entities (models) drawn by a rendering 
system. These entities are modified by the protocols 
(controllers) that translate network messages into state 
changes. New protocols can be loaded at run-time to 
extend the behaviors of entities. The packets are sent via 
multicast, and the system allows many protocols to 
share a single multicast socket. Network traffic is con¬ 
trolled with an area-of-interest manager. 

The Distributed Interactive Virtual Environment 
(DIVE) system (Frecon & Stenuis, 1998) is designed to 
scale to many participants while maintaining a high level 
of interactivity at each site. It is based on a peer-to-peer 
architecture that uses reliable multicast to maintain a 
database that is replicated at each peer. Using a hierar¬ 
chical partitioning of the database, only part of the data¬ 
base can be replicated at some peers. To maintain highly 
interactive rates, some copies of the database may be 
updated faster than others, but there are mechanisms to 
ensure equality over time. 

MASSIVE-2 (Greenhalgh, 1996) uses the concept of 
a local object, or artifact, and remote views of that arti¬ 
fact. These artifacts are paged in and out of remote ap¬ 
plications. A spatial model of interaction is used, in 
which a remote application has a focus that defines a 
subgroup of the artifacts to be paged in and out, instead 
of copying the entire database. Artifact state changes are 
distributed using reliable multicast. 

Not all work has been solely for immersive virtual 
environments. Some collaborative AR systems have been 
built, typically for small groups of colocated users. One 
example is the Shared Space system (Billinghurst, Baldis, 
Miller, ScWeghorst, 1997) for computer-supported 
collaborative work using AR. 
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Typically, users operate closely with one another and 
latency requirements are extremely high. Another sys¬ 
tem designed for augmented and virtual reality is 
COTERIE (MacIntyre & Feiner, 1996), which provides 
useful semantics through its notions of Distributed 
Shared Memory and Callback Objects. Distributed 
Shared Memory allows many applications to share the 
same data objects, while Callback Objects allow applica¬ 
tions to be notified of changes to those data objects—an 
event-like mechanism. The Studierstube system (Reit- 
mayr & Schmalstieg, 2001) extends the concept 
through its use of an extensible scenegraph of applica¬ 
tion objects that is distributed to all users. 

3 The BARS Event Distribution System 

First, some terms will be defined as they are 
used in this discussion. A session consists of one or 
more applications, or program instances, which may 
exist in any number on one or more machines on a 
network. Each application uses a core set of libraries 
to maintain a local database of objects and to com¬ 
municate over a network. Applications may also in¬ 
clude modules to read data from sensors, draw the 
augmented display, and perform other tasks, depend¬ 
ing on the purpose of the application. The local data¬ 
base is a copy of a master database that is shared be¬ 
tween all applications on the network. The 
distribution system is responsible for selectively repli¬ 
cating the master database in all applications. 

The distribution system is based entirely on the con¬ 
cept of events. Events are used to instantiate objects (in 
effect, to transmit a view of a database between sys¬ 
tems), to update existing objects, and to provide other 
non-database status information such as protocol man¬ 
agement data. The event distribution system is based on 
three components: replicated object repositories, event 
transporters, and communication channels. These com¬ 
ponents will be described below, as will bridge applica¬ 
tions, which communicate with outside information 
systems, and some other uses of the event distribution 
system. 


3.1 Replicated Object Repositories 

All of the data for a scenario is stored in an object 
repository. The data consists of the mosdy static models 
of the physical surroundings (buildings, streets, points 
of interest, etc.), dynamic avatars that represent users 
and other entities, and objects created to communicate 
ideas, such as reports of enemy locations, routes for us¬ 
ers to follow, and digital ink. This repository is repli¬ 
cated in whole or in part for each application. 

When an application starts, it loads an initial set of ob¬ 
jects from a number of sources, including saved databases, 
other applications already running on the network, and 
files specified on the command fine. The initial set of ob¬ 
jects typically consists of street labels, landmarks, building 
information, and other terrain-like information, as well as 
an initial set of objectives, routes, and phase markers for 
the current task. Since the user is given a database to 
start, and everything else in the wearable system is self- 
contained, the user will have a working AR system even 
if all network connectivity is lost during an operation. 

Although network limitations may hamper wireless 
communications for the mobile users, there are few lim¬ 
itations on the base users. Base users are those who use 
stationary systems and are not mobile, such as users at 
fixed command centers. Their applications run on sta¬ 
tionary Virtual Reality (VR) systems such as a desktop 
computers, 3D workbenches, and immersive VR rooms. 
Using the same distribution system, they can have high 
levels of detail and interaction by taking advantage of 
the increased bandwidth for replicating more objects 
and seeing change events at a higher frequency. 

3.2 Event Transportation 

The heart of the event transportation system is the 
Object and Event Manager. The Object and Event 
Manager is responsible for dispatching events within an 
application and distributing those events to remote ap¬ 
plications. When the Object and Event Manager re¬ 
ceives an event, it places that event on an asynchronous 
event queue. An event-dispatching thread delivers the 
event to all the listeners that are subscribed to receive 
the specified event type. The event-dispatching mecha- 
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BARS Database Objects BARS System Objects 



Figure 3. Event distribution within an application: arrows show 
event movement 


nism maintains two sets of data—the set of valid event 
types, and the set of listeners registered for each event 
type. Because the event system is based on the Java Ab¬ 
stract Window Toolkit event model (Sun Microsystems, 
2003) the Reflection Application Programming Inter¬ 
face is leveraged to achieve these steps. Each event type 
is implemented in its own class. For each event type, a 
listener interface is deflned, to be implemented by inter¬ 
ested objects. When an object is registered with the Ob¬ 
ject and Event Manager, its instance type is queried and 
it is registered to receive all event types for which it has 
implemented listener methods. It is possible to dynami¬ 
cally extend the set of events and listeners handled by 
the dispatcher at run-time. 

The following is an example of the life of an event 
within an application that tracks a user’s position. The 
user’s position is updated by calling a method in the 
user object to set its pose based on data gathered from 
tracking devices. In turn, this method creates an event 
that encapsulates the change in pose. The event is en¬ 
queued at the event dispatcher. The dispatcher later 
sends the event to all listeners, including the initial ob¬ 
ject itself, as well as other system components (such as 
the graphics system, which updates the viewpoint). 

Note that the object’s pose isn’t set until it receives the 
event back from the dispatcher (the alternative is to set 
the position at the same time the event is sent)—this 
way, the order of events is preserved. Figure 3 shows 
the flow of events within an application. 

The propagation of events within a single application 
instance has been described above. This event mecha¬ 


nism was extended to allow many separate applications 
to trade events by creating Event Transporters. Event 
Transporters allow Object and Event Managers in dif¬ 
ferent application instances to send and receive events 
over Internet Protocol (IP). Figure 4 shows the flow of 
events between applications. If an event is tagged as dis¬ 
tributed, an Event Transporter serializes the event and 
broadcasts it to other applications. The Event Trans¬ 
porters in remote applications synthesize the event ob¬ 
ject and dispatch it on those applications’ event queues. 
The system uses several types of transporters based on 
IP multicast, the Lightweight Reliable Multicast Proto¬ 
col (LUMP) from INRIA (Liao 1998), and a combina¬ 
tion protocol called the Selectively Unreliable Multicast 
Protocol (SUMP) that combines IP multicast and LUMP. 
Typically, application instances use SUMP on the local 
network. To communicate outside of the local network 
(where multicast is typically Altered out) TCP /IP trans¬ 
porter and bridge are used (described later in Section 3.4). 
Because of the connectionless nature of IP multicast, die 
distribution is robust—the network connection can be 
unreliable and the user application will still function, al¬ 
though without network updates at some times. 

As events are created, they are tagged “reliable” or 
“unreliable” designating how they should be trans¬ 
ported. Object creation and deletion events are always 
sent reliably. Object changes are sent reliably or unreli¬ 
ably based first on whether the modification is relative 
to other changes or not. Relative changes have an or¬ 
dering and each one is important, so those are sent reli¬ 
ably. Non-relative changes, such as the constant updates 
of a user’s position, are mostly sent unreliably since if 
one were missed, the next would overwrite it anyway. 
Periodically, these non-relative changes are sent reliably. 
This policy makes the assumption that the implementa¬ 
tion of IP networking in a real operation may drop IP 
packets often, making reliable multicast expensive, and 
so events are not sent reliably unless they are thought to 
be truly necessary. 

3.3 Channels 

The problem with the event distribution mecha¬ 
nism described above is that all events for all objects 
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Figure 4. Event distribution between applications: arrows show event movement 


would be broadcast to every single application. Creating 
copies of every object for every user and updating those 
replicas would swamp the network with information 
that would be irrelevant for many users. To overcome 
this problem, the database is only partially replicated in 
each application instance. 

In creating this replication mechanism, the uses of 
BARS drove the policies. One condition to consider is 
that a mobile user can see only so far and can deal with 
information only in a relatively small radius, so a spatial 
area-of-mterest mechanism was considered. It is not 
necessarily the case that a mobile user only cares about 
objects that can be seen from his or her current position 
in the real world; for example, a mobile AR application 
may include an overhead map mode in which the user 
can zoom out to an arbitrary height to observe objects 
within a huge radius around the current position. How¬ 
ever, it seems that there would be few situations in 
which a mobile user would request information about 
objects farther away, at the horizon for example, so for 
most situations, a simple area-of-interest mechanism is 
reasonable. 

Another condition is the type of information that is 
being distributed. Even if some objects are near a mo¬ 
bile user, they may not be important and might only 
cause distraction. Alternatively, the objects may indeed 


be too far away to be seen, but very important, such as 
with possible sniper locations. For these cases, a simple 
area-of-interest mechanism isn’t sufficient. In an earlier 
paper (Julier, Lanzagorta, Sestito, Rosenblum, Hbllerer, 
& Feiner, 2000), a filterrng mechanism for mobile aug¬ 
mented reality was described. This frltering mechanism 
operates on the local object database within an applica¬ 
tion instance. It does not show users objects in which 
they have no interest in order to reduce display clutter. 
In practice, it simply hides objects from the user—^it 
does not actually control whether or not the application 
instance holds replicas of these objects or receives events 
related to these objects. 

Keeping these situations in mind, channels have been 
developed. The term is overloaded in the literature, but 
in this system, a channel is a set of related objects. It is 
implemented as an instance of an event transporter and 
a multicast group designated for that transporter. An 
application can join an arbitrary number of channels and 
create new channels, until all available multicast groups 
are allocated. Figure 5 shows a single application using 
two channels. 

One example of a channel is a set of objects in a cer¬ 
tain spatial area. As users move from location to loca¬ 
tion, they can join and leave channels based on spatial 
areas. Another example is the set of hazardous objects; 
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Figure 5. Application joined to two channels: arrows show event 
movement. 


Figure 6. Lightweight channels allow machines to share certain 
data, bypassing the regular distribution system. 


while in the previous example the application instance 
would replicate only objects nearby, the hazardous ob¬ 
jects channel could cover a larger area, but only include 
those hazards. Also, BARS incorporates several interac¬ 
tion modules that produce subsequent objects. For ex¬ 
ample, one interaction module is responsible principally 
for real-time, interactive geometric construction (Bail- 
lot, Brown, & Julier, 2001). It allows users to collabo- 
ratively place points and build new objects from those 
points; in this case, the intermediate points would not 
be visible to other users because they are placed in a 
channel joined only by the constructing users. Other 
users would see only the final objects. Another interac¬ 
tion module lets a user draw digital ink for interpreta¬ 
tion by a multimodal interaction system—this ink is 
turned into new objects or user-interface commands. In 
this case, the application instance of the user drawing 
the ink would be placed in a separate channel, joined by 
the application to interface with the multimodal system. 
The ink is placed in this channel so that other users will 
not see these sketches out of context. 

In some cases, a set of applications may need to by¬ 
pass the general event distribution system. “Lightweight 
channels” allow specific parts of an application to com¬ 


municate direcdy over the network. This mechanism is 
used to coordinate a specific data set on many machines 
at interactive (30 updates per second or higher rates), 
such as in a cluster of eight machines driving a stereo 
four-wall immersive VR room. In that case, the user’s 
viewpoint must be well coordinated between the ma¬ 
chines, because it can be very disorienting to the user if 
the walls of the room show differing viewpoints even for 
very short amounts of time. For such applications, the 
viewpoint, and also the tracked device data (such as 
wand position), are sent over lightweight channels to 
only the cluster machines. At the same time, the distrib¬ 
uted database continues to be maintained among the 
cluster machines and every other application in the ses¬ 
sion using the regular data distribution system as de¬ 
scribed earlier in this section. While the regular distribu¬ 
tion system is not fast enough to maintain interactive 
rates when distributing the viewpoint or tracker data, it 
can handle database updates across the cluster machines 
and the rest of the session applications at reasonable 
rates (usually well over five updates per second). More 
performance data will be given in section 4. Figure 6 
shows how a VR cluster works with the distribution 
system. 
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Figure 7. A bridge application allows applications in a BARS session 
(two wearable systems, two VR viewers) to interact with data from an 
external system. 


3.4 Bridges 

As alluded to in the previous section with the mul¬ 
timodal interaction example, some applications commu¬ 
nicate with external information systems. These applica¬ 
tions are called bridges. They join both the BARS 
distribution system and an outside system and translate 
object creation and changes between BARS and the 
outside system. By maintaining maps between BARS 
objects and these outside objects, those objects can be 
represented in BARS and vice-versa. Figure 7 shows 
how a bridge application fits into a session. Two systems 
with which BARS can communicate are the Columbia 
Mobile Augmented Reality System (Hollerer, Feiner, 
Terauchi, Rashid, & Hallaway, 1999) and the Oregon 
Graduate Institute’s QuickSet multimodal interface 
(Pittman, Smith, Cohen, Oviatt, & Yang, 1996). 

A TCP/IP transporter for this distribution system 
was mentioned earlier. Although the system is designed 
primarily for IP multicast, sometimes the need to con¬ 
nect to networks that block multicast arises. For this 
case there is a simple TCP/IP bridge application that 
joins local multicast groups and creates socket connec¬ 
tions to other applications outside of the local network 
through TCP/IP Event Transporters. This can be a bit 


of a bottleneck, but one TCP/IP bridge per outside 
application can be created if necessary, and effective cre¬ 
ation of channels can help limit the amount of data 
transferred. 

3.5 Other Uses 

One final aspect of this event distribution system 
to be discussed is its flexibility. Although the system was 
designed to carry information about objects in the data¬ 
base, at its heart it is still a distributed event system. The 
same base event types and transporters are used for 
other purposes. One set of events are “metaevents” to 
configure the Event Transporters; a similar set of events 
configures channels. Another set of events is used to 
distribute the user interface of an application to remote 
systems. For example, when a new user is trying out the 
mobile system and is unfamiliar with the user interface, 
the mobile system can be controlled from another com¬ 
puter (usually a handheld computer or PDA) by sending 
and receiving events that are handled by the user inter¬ 
face system. Yet another set of events is used for evalua¬ 
tion test studies: to trigger the tests, the test administra¬ 
tor uses an application configured to control the test 
subject’s application This control happens simply by 
registering a new set of events and listeners and using 
the existing event transport system. 

4 Performance Measurements 

Now that the mechanisms used to control the net¬ 
work resource usage by the applications have been de¬ 
scribed, the performance of the system will be exam¬ 
ined. The first issue to consider is the impact of using 
serialized Java events instead of writing and reading raw 
data into network packets through using code tailored 
to each event type. The serialized event sizes measured 
in a simple test ranged from 776 bytes (for a typical 
object-attitude-change event) to 5919 bytes (for a cre¬ 
ation event for a path of twenty points). If specialized 
but simple algorithms encoded the data, the attitude- 
change event would need at least 60 bytes: 48 bytes for 
the six doubles representing the attitude (three doubles 
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Figure 8. Network usage at session start. 


Figure 9. Event throughput at session start. 


each for position and orientation), plus 12 bytes for 
three long integers specifying the source, target, and 
type of change. The path-creation event in this example 
would require at least 492 bytes: 12 bytes for three long 
integers to specify source, target, and type of creation, 
plus 480 bytes to encode twenty three-dimensional po¬ 
sitions that make the points of the path. So, it appears 
that using serialized Java events inflates the event sizes 
by an order of magnitude over a simpler hand-coded 
system that would be harder to extend. For this research 
in augmented reality, having the flexibility to add new 
event types at run-time without any specialized code is 
important, so the penalty is accepted. 

Next, distribution throughput in a set of test cases 
designed to simulate typical usage scenarios will be ana¬ 
lyzed. In each test case, there is an existing session of 
one to five users. The session uses SUMP (the combina¬ 
tion of LRMP and IP Multicast transporters) to trans¬ 
port events over the network in a single channel. Each 
of the users has created six notational objects (five point 
objects and a line of many points). A new user joins this 
session using 802.11b wireless networking and mea¬ 
sures distribution system throughput in both bytes per 
second and events per second (since event sizes vary 
quite a bit) for the two transporters. These measure¬ 
ments are taken just after the new application starts up 
and after it has been running for five minutes. The test 
is repeated for three different user-position-update rates 


(how often the users send their positions to the net¬ 
work): 30 updates per second (UPS), 6 updates per sec¬ 
ond, and 3 updates per second. Thus, the independent 
variables are the number of users in the session, UPS 
rate, and time of measurement. The dependent variables 
are bytes per second and events per second measured by 
the new user. In reading the test summary, the reader 
will notice that the graphs show upper limits of data 
throughput rates that do not approach the theoretical 
upper limits of 802.11b. The measured throughput is 
affected not only by total network load but also by the 
speed of the machine collecting data, because it needs 
to process each event. Optimizing the implementation 
and using a faster machine may produce higher absolute 
numbers, but the scalability properties will remain the 
same. 

As an application starts, it queries the existing applica¬ 
tions in the session for distributed database objects. To 
provide redundancy in case of network outage, each 
application sends its set of distributed objects using reli¬ 
able events (so in this case, they travel over LRMP). 

This technique needs to be improved, however, because 
it provides much duplicate data, and grows geometri¬ 
cally in network usage with the number of users; the 
LRMP data points in the graphs in Figures 8 and 9 
show this effect. The applications also continuously 
send, at the specified rate, positional updates, primarily 
over the unreliable transport (IP Multicast). When the 
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Figure 10. Network usage over time. 


Figure I I. Event throughput over time. 


existing users are sending thirty positional updates per 
second, the distribution system on the data gathering 
machine appears to become saturated at four users. The 
IP Multicast traffic grows linearly with the number of 
users, as expected, except where it actually decreases as 
the IP Multicast packets are dropped in favor of the 
LUMP packets. This phenomenon can be seen with as 
few as three users using the highest update rate in the 
test. 

As the graphs in figures 10 and II show, after the 
session has been running for five minutes at the lower 
update rates, the total network usage (LUMP and IP 
Multicast combined) grows only slightly more than lin¬ 
early with the number of users, as the small, unreliable 
updates begin to dominate over time. However, with 
high update rates for position, the network remains sat¬ 
urated well after the initial database duplication; remem¬ 
ber that every tenth positional update is sent reliably, so 
even after the initial database duplication, there is still 
significant traffic using LUMP. 

These measurements show that, in the test case of six 
updates per second, the distribution system easily kept 
up with five users over time. This capacity may seem 
insufficient, and with more optimization it can be 
greatly increased, as discussed earlier. However, for one 
driving scenario—being able to see the locations of 
friendly forces—it is more than enough for a small team. 
It is clear, however, that using serialized Java events is a 


heavyweight way to share data, and that a better opti¬ 
mized networking component using the basic architec¬ 
ture presented could provide much better throughput 
in a version of BARS constructed for actual operations. 

S Conclusions and Future Work 

An event-based data distribution system imple¬ 
mented for BARS, a mobile augmented reality system, 
has been presented. It addresses some requirements en¬ 
countered that developers of networked virtual environ¬ 
ments have not addressed, such as working on unreli¬ 
able network connections, handling many types of users 
through its channels, working well in both high-band¬ 
width (immersive VR) and low-bandwidth (mobile AR) 
applications, communicating with outside systems 
through its bridges, and being flexible enough for non¬ 
database data distribution. 

For future work, the channel concept needs to be 
developed further. Intelligent algorithms to automati¬ 
cally create channels and join applications to those chan¬ 
nels would be the next step. These algorithms would 
take into account such factors as: database object types; 
the user’s tasks, location, and short-term interests; and 
network conditions. Also, bridge applications to widely- 
used military information systems will be created. An¬ 
other area to consider is the problem of “partitioned” 
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data networks (Reijers et al., 2002). This condition 
arises when a mobile user (or set of mobile users) is out 
of contact for prolonged periods of time. During this 
time, multiple state updates have occurred and it is nec¬ 
essary to synchronize the systems again. 
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